The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A user authentication process is normally used in networks that carry data, voice or other information to determine whether a user or client seeking to access a network actually is who the user purports to be. Numerous message protocols have been developed to specify how to perform authentication with network devices such as switches, routers, gateways, and gatekeepers. Typically, an authentication protocol requires a client to prove its identity by offering a data credential that is verified in a secure manner by an authentication server. Some such servers also perform network access control and accounting functions and therefore are termed authentication, authorization and accounting (AAA) servers. A commercial example is CiscoSecure Access Control Server, from Cisco Systems, Inc.
The emergence of numerous diverse authentication protocols spurred a movement toward developing a generalized authentication protocol that could be extended to support various platforms and purposes. An authentication approach for network devices is described in L. Blunk et al., “PPP Extensible Authentication Protocol,” IETF Request for Comments 2284, March 1998, and other aspects of EAP are described in RFC 2716, 3579, etc. The “EAP” approach of RFC 2284 provides a generalized way for a first network element to authenticate the identity of a second network element. EAP is becoming the preferred user authentication protocol for most types of network sessions across different network devices. In large part, this popularity stems from the extensible nature of EAP, which allows any device that provides generic support for the protocol to transparently support new authentication protocols, known as EAP methods.
EAP implementations have been developed for many specific contexts. For example, in the context of mobile wireless devices that use the Global System for Mobile communications (GSM), an approach for authentication and deriving session keys using the GSM Subscriber Identity Module (SIM) is described in H. Haverinen et al., “EAP SIM Authentication,” IETF Internet-Draft, February 2003. In these contexts, EAP generally results in exchanging authentication credentials, and may include a key exchange in which peers acquire keys needed to decipher packets sent under a link layer protocol, such as IEEE 802.11.
Wireless local area networks such as those that use the 802.1x protocol for wireless communications now commonly use EAP for user authentication. A wireless client device, such as a laptop computer, that is seeking to obtain network access is termed a supplicant. An AAA server provides user authentication services to an access router that intercepts requests of the supplicant; the access router has the role of a client with respect to the AAA server.
EAP supplicants and servers are typically used in a relatively simple operational configuration in which one encrypted outer EAP method protects messages communicated using one inner EAP method. For example, the outer method may be EAP-PEAP and the inside method may comprise EAP GTC, in which the user uses a cryptographic token card to supply a user credential, or the inside method may comprise Microsoft Challenge-Authentication Protocol (MS-CHAP).
However, EAP sequences are becoming more widely deployed inside tunneled EAP methods, such as EAP-PEAPv2 and EAP-FAST, to provide authentication using more than one authentication factor, user authorization, validating that the supplicant has a required software configuration (“posture validation”), and other processes. These approaches introduce a greater burden on AAA servers, as these new methods require multiple cycles of challenge and response messages, and each message may require breaking into small fragments because they exceed the maximum transportable unit size of the transport medium (e.g., a WLAN) or transport protocol. Therefore, it is desirable not to burden an AAA server with a user authentication transaction unless it is relatively certain that the supplicant can perform as required in the transaction.
Further, new AAA server features may include more flexible policy-based access control. For example, authentication protocols no longer need to be statically pre-programmed into devices and supplicants. However, the whole authentication message sequence can fail at the last stage if the supplicant is not configured correctly. For this further reason, it is desirable not to initiate a message sequence if the supplicant cannot complete the sequence.
Type-length-value triplets (TLVs) are now used inside tunneled EAP methods to create sequences of EAP methods. This approach is required because the EAP specification states that top-level EAP methods cannot be chained. Hence an EAP method only receives an EAP-TLV, and a sequence of methods occurs conceptually “inside” the EAP-TLV exchange. As defined in RFC 2284, each EAP message includes a “Type” field, which indicates the EAP method being used for the authentication of the session. The Type field is required regardless of which encapsulation type is used to transport the EAP message, such as Remote Authentication Dial In User Service (RADIUS), which is defined in IETF RFC 2138; point-to-point protocol (PPP), as defined in RFC 1661; EAPOL, etc. EAP-TLV is EAP type 33. A protected version of EAP using TLS is also available, and is effectively the same as using a TLV inside EAP-PEAP or EAP-FAST.
Co-pending U.S. application Ser. No. 10/071,455, filed Feb. 8, 2002, claims a security capability negotiation in the context of SSL ciphersuites, and has the following abstract: “A method and apparatus are disclosed for providing data from a service to a client based on the encryption capabilities of the client. Cipher suite lists are exchanged between a client and an endpoint. On the endpoint, the cipher suite list incorporates a mapping of cipher suite names to services. The endpoint uses the client's list of cipher suites in conjunction with the mapping of cipher suite names to services to determine a cipher suite match. A service is selected based on the cipher suite match. A server farm is selected based on the service. The client is informed of this cipher suite match and the endpoint retains knowledge of the cipher suite match throughout the session. Therefore, the encrypted connection between the client and the endpoint can be disconnected and later reestablished to provide data from the particular server.” Other handshake mechanisms and negotiation protocols have been used in other contexts, but they do not address the needs identified here.
Based on the foregoing, there is a clear need for an approach for determining the authentication capabilities of a supplicant before initiating a authentication process that may consume significant server resources. It would be useful to have such a mechanism that is compatible with existing protocol infrastructure in general, and compatible with EAP in particular.